在我們團隊的 dbt CI 流程中，第一階段是識別被改動的 models。這是因為在測試環境執行 models 時，我們不希望執行所有 models，以避免產生大量的查詢成本。

要在 CI 階段只執行被改動的 models，我們需要先找出這些 models 檔案。我們有兩種方法來實現這一目標。

第一種是我們最初的做法，利用 git：首先找出當前分支和主分支的共同祖先，然後比較共同祖先與當前分支，識別出被改動的檔案。接著，我們檢查這些改動的檔案是否位於 models 資料夾中。如果是，我們就去除檔案副檔名並回傳檔案名稱。

然而，這種方法存在一個小問題：當 model 檔案本身沒有改動，但編譯後的結果有變化時，git 無法捕捉到這種改動。

什麼情況下會發生這種情況呢？當 model 中引用了 macro，而 macro 有所改動但 model 本身沒有變化時，編譯的結果可能會因為 macro 的改動而改變。要捕捉到這種改動，我們需要使用 dbt state。這也是我們團隊後來採用的改進方法。

dbt state 介紹

dbt state 是用在 —select 後的篩選 models 的指令，最基本指令如下

dbt run --select "state:modified" --state path/to/artifacts

--select "state:modified" 告訴 dbt 這次執行要選取有異動的 models。dbt 透過 manifest.json 檔案來識別這些異動。

manifest.json 是 dbt 中的關鍵檔案，每次 compile 或 parse 時都會生成。它包含了 dbt models、macro、test 等詳細資訊，如 model 的 database、schema 資訊、model compile 結果，以及 model 引用的 macros 和 models 等。

dbt state 通過比對更改前後的 manifest，來分析兩者中哪些 models 的資訊有變化（注意：只要有任何資訊改變就會被識別出來）。

由於 state:modified 會篩選出所有資訊有異動的 models，如果想要篩選特定類型的異動，可以使用更精確的條件。以下是一些可用的篩選條件：

• state:modified.body：model 中的 SQL 程式碼有改變，包含空格、換行、欄位命名改變都會被視為 SQL 程式碼改變
• state:modified.configs：model config 中的參數有改變，如改變 model 的 database、schema、alias 等 config 參數
• state:modified.macros：當 macro 程式碼有異動時，所有使用此 macro 的 models 都會被識別出來

還有更多篩選條件可參考 dbt 文件說明

了解篩選條件後，下篇讓我們來探討如何生成關鍵的 manifest 檔案。